Apache Doris 在金融壹账通指标中台的应用实践
金融壹账通作为中国平安集团的联营公司，依托平安集团 30 多年金融行业的丰富经验及自主科研能力，向客户提供“横向一体化、纵向全覆盖”的整合产品，以“技术+业务”为独特竞争力，帮助客户提升效率、提升服务、降低成本、降低风险，实现数字化转型。在搭建数字化解决方案的过程中，面对传统报表制作过程中指标口径不统一、计算重复与交付效率低等痛点，金融壹账通决定基于 Apache Doris 搭建一体化指标数据服务平台，实现指标集中构建和管理、减少 ETL 开发工作量等业务目标。本文将详细介绍金融壹账通两代架构的演进过程，分享数据服务平台的建设经验与应用实践，向大家展示如何基于 Apache Doris 在多表关联与高并发场景下实现毫秒级查询响应。
金融壹账通是面向金融机构的商业科技服务提供商（Technology-as-a-Service Provider），为国家高新技术企业。作为中国平安集团的联营公司，金融壹账通依托平安集团 30 多年金融行业的丰富经验及自主科研能力，向客户提供“横向一体化、纵向全覆盖”的整合产品，包括数字化银行、数字化保险和提供金融科技数字基础设施的加马平台，以“技术+业务”为独特竞争力，帮助客户提升效率、提升服务、降低成本、降低风险，实现数字化转型。
在搭建数字化解决方案过程中，我们主要利用指标（如银行经营业绩指标：客户 AUM）来直观地反映企业经营状态，通过指标开发报表以帮助业务人员进行数据分析，进而驱动管理决策、赋能数字化经营。我们早期的报表制作方式是由不同的业务线人员根据自己的业务范围，使用不同的分析工具去定义指标，这种传统的方式在跨业务合作时会带来两大痛点：
指标口径、标准不统一：各个业务线生成的报表堆积如山，由于使用不同分析工具，使对接数据源多样复杂，导致指标口径相互打架的问题。
指标计算重复、交付效率低：开发流程需要业务方提出后，由 IT 人员下探数据源并加工，再制作报表、上线验收。整个过程中，IT 需要和业务多次沟通来同步信息，导致普通报表开发需要两周时间完成。
为了解决这两大问题，我们集团内部决定自研一体化指标数据服务平台，通过建立指标体系贴合客户战略目的，借助服务平台规范开发流程和使用方式，实现指标集中构建和管理。同时，使用 OLAP 查询引擎助力指标开发与应用，让业务人员能够快速找到所需数据，减少 ETL 开发工作量、缩短报表开发周期、加速指标发布与可视化看板生成的时间。
在数据服务平台建设过程中，金融壹账通经历了两代数仓架构演进。第一代架构基于 Apache Kylin 预计算的方式查询指标数据，并在架构使用后，发现其查询性能不足的问题。为了满足业务诉求，我们进一步开展 OLAP 选型调研，最终引入 Apache Doris 进行架构升级，借助 Apache Doris 的高性能分析能力为指标高效查询保驾护航。
本文将详细介绍金融壹账通两代架构的演进过程，分享如何基于 Apache Doris 搭建指标统一构建、查询、治理的一体化数据平台，并在多表关联与高并发场景下实现毫秒级查询响应。
在业务初期，我们基于 Apache Kylin 进行 T+1 报表开发，上图是指标构建和查询的过程。在指标构建过程中，开发人员会根据选择的指标和维度进行 SQL 拼接， 通过 API 调用 Apache Kylin 的方式对各个维度进行与计算，完成模型构建和数据加载。在指标查询的过程中，采用快速查询和下压查询的组合策略，如果查询字段命中 Cube， 我们可以在 Apache Kylin 直接查询；如果没有命中，则下压至 Presto 再进行查询。
随着业务量不断增长，使用平台的业务用户越来越多，在面向客户推广与集团内部使用过程中，我们发现该架构在以下方面表现不足，无法满足我们的业务诉求：
灵活分析：Apache Kylin 预计算只能满足部分场景需求，没有办法满足更灵活的分析需求。
查询性能：当查询字段未命中 Cube 时，需要下压至 Presto。而 Presto 的查询性能得不到保障，特别是在查询码值的场景下，会遇到查询超时的现象，阻碍指标发布。
使用与运维成本：Apache Kylin 架构在查询与开发过程中需要使用多套组件，造成了过高的维护成本。
基于第一代架构的使用经验，我们急需找到一个既可支持指标多表关联查询的场景，又可以达到降本增效的 OLAP 引擎。带着这样的诉求，我们对比了当下比较热门的 OLAP 引擎进行系统选型，从多表关联场景、使用协议、使用成本、金融应用场景与案例四大方面进行比较。
OLAP 选型对比
我们首先排除了 TiDB ，主要因为其更倾向于满足 TP 需求，在应对大数据量分析场景时性能相对不足。其次，我们也排除了 Clickhouse 和 Greenplum。由于 Greenplum 单机性能较差，不适用于我们的查询场景；Clickhouse 虽然在单表查询性能表现不错，但是不支持 MySQL 协议，多表 Join 无法发挥性能，因此两款产品均不能满足我们对于海量数据在多表关联场景下的查询诉求。
最终，在集团内部其他子公司的使用反馈与推荐下，我们发现 Apache Doris 非常符合我们的诉求，并坚定不移地选择 Apache Doris 进行架构升级，主要原因如下：
开发简易方便：Apache Doris 不仅兼容 MySQL 协议，还能够支持标准的 SQL 查询语法使开发简单方便。
复杂场景多表关联查询性能：Apache Doris 支持分布式 Join、明细聚合等方式，在进行多表 Join 时能够提供多种优化机制，提升查询效率。同时 Apache Doris 还支持物化视图与索引功能来完成预计算效果，在命中物化视图时实现快速查询响应。
运维简单、方便扩展：Apache Doris 的整体部署只有 FE 与 BE 两种角色，极大简化了架构链路，使架构无需再依赖其他组件，实现低成本运维。
架构 2.0 ：Apache Doris
基于 Apache Doris 的性能优势，我们从数据迁移和应用两方面进行了架构升级。在数据迁移过程中，Apache Doris 替代了第一代架构中 Apache Kylin 与 Presto，统一进行指标数据存储、处理、计算，并利用 Duplicate Key 模型对明细数据进行查询，使用 Range 进行时间分区并制定维度关联键作为 Key，有效解决了早期架构中 Presto 明细查询时性能不足、并发不够的痛点。同时，Apache Doris 在查询引擎方面采用了 MPP 模型，具备高并发、低延迟的计算能力，使节点间和节点内都能够并行执行，支持多个大表分布式 Shuffle Join，能够满足我们对复杂场景下多表关联查询的需求。
在应用方面，我们重写了 MySQL 兼容的查询引擎，当使用指标平台进行查询时，不再需要借助架构 1.0 中 Apache Kylin 调用接口、从页面中点击重跑指标等一系列比较繁琐的工作，开发人员可以基于 Apache Doris 直接使用 MySQL 语法进行查询，极大简化了指标发布过程。
Apache Kylin vs. Apache Doris
我们选取了指标平台常见的多表关联场景对 Apache Kylin 与 Apache Doris 进行性能对比，发现 Apache Doris 在查询性能与指标开发效率上表现都更为优异。如上图所示，Apache Doris 在数十万数据集关联情况下，查询响应基本达到毫秒级。同时，我们不再需要等待 Apache Kylin 完成 Segment 构建后使用指标，指标发布从原来的平均 30 分钟到现在的即发即用，显著提升指标开发效率。
Apache Doris 的引入还大大节省了指标存储空间，符合集团降本的需求。集团内部的其他业务线（产险、寿险）也因此开始对 Apache Doris 进行铺开使用。新架构的升级不论是从硬件、人力、时间上都实现了非常高效能的提升，成为一体化数字指标平台建设的强大后盾。
在架构升级完成后，我们可以建设统一的指标体系，通过指标内容、BI 与 AI 技术构建平台功能，共同建设一体化指标数据平台。
构建指标体系
金融壹账通借助归因关系分析帮助机构自上而下对指标进行建设，梳理核心 KPI 并逐层拆建指标，保障指标体系的完整性与可落地性。根据指标生成的方式，将指标类型进行细分，以银行营销场景举例，针对银行资产管理中对客户资产总值的衡量指标（AUM）可以细分为以下三种类型：
原子指标：通过数据源接入到指标平台的最细粒度指标，一般为表字段，例如 AUM 余额。
衍生指标：为了进一步指标分析，平台自动衍生一系列指标，如 AUM 同比、环比净增等。
派生指标：为了满足复杂的指标分析场景，基于原子指标，添加过滤条件或者结合其他指标进行运算，帮助用户自助配置看板，节省取数过程。例如用户希望生成客均 AUM 余额进行分析，平台可以借助原子指标 AUM 余额与全量客户数生成该指标。
构建指标平台功能
指标平台的功能实现主要依赖于 Apache Doris 数仓架构的支持，整体指标线上流程基于开发和业务配合完成。开发人员首先统一在平台进行元数据管理和指标录入，包括对加工报表的底表进行注册，配置中间表的数据粒度和更新频率等，接着对表进行关联、录入指标名称和指标口径信息。在输入指标基础信息之后，交由业务人员负责，选择对指标分析所需维度，对指标进行发布。
基于以上两个步骤，我们可以在平台中对指标数据进一步分析。如上图左侧所示，指标平台提供了各种柱状分析视图，业务人员能够可视化地查看指标排行榜看板，分析各银行分行 AUM 排名情况。同时，我们融入了 AI 智能算法，借助时序模型检测指标异常，通过根因分析算法辅助 KPI 检视，并分析指标异动原因。对于存量指标，平台提供了价值评分体系，能够及时下线价值低的指标，达到边使用边治理的目的。
一体化数据平台的建设完全解决了金融壹账通在传统报表开发时指标口径不统一和指标重复计算的问题。在分析效率方面，我们希望在复杂的多表关联场景下，实现接口 600 毫秒响应时间、查询响应在 100 毫秒内的目标。因此，我们对 Apache Doris 进行了测试与调优，从数据的前期准备、集群部署、模型调优三方面分享 Apache Doris 在该场景下的应用实践。
在前期数据准备过程中，考虑到我们的数据集和官网测试的 SSB 数据集很相似，我们选择了官网推荐的开发测试环境配置，选用 Apache Doris 1.1 版本进行测试。因为我们是通过 Python Mock 数据直接生成 CSV 文件，所以我们采用 Stream Load 的方式分批导数，每次导入的 CSV 文件都在 Stream Load 推荐的文件大小 1 - 10G 以内，最终数据压缩比达到 3 : 1 ，但单节点导入速度超过 40 MB /s。
在集群部署过程中，为了对指标性能和服务器监控（CPU、IO、磁盘和内存），我们借助 Prometheus 导入 Apache Doris 监控模版对集群部署监控，由 Prometheus 接收 Apache Doris 暴露监控项，再借助 Grafana 进行可视化呈现。
在准备工作完成后即可开始进行大表关联查询，我们选择了耗时较长的 SQL 来查询指标趋势图。基于毫秒级查询目标，我们实施了两个优化解决方案。第一个方案是利用 Colocation Join 将数据在建表时提前聚合。第二个方案是借助 Audit Loader 的方式收集高频 SQL，反向优化数仓的表构建以及改写 SQL，使用偏宽表设计代替之前的星型 / 雪花模型。通过两个方案的测试与评估，我们发现第二个方案能够在查询响应、服务资源节省中达到更加显著的收益。
亿级数据多表关联查询，实现毫秒级查询响应
我们将 SQL 查询执行时间进行了统计，如上图所示在采取方案一 Colocation Join 的方式时，查询响应时间从之前的 5 秒提升至 1 秒。虽然查询效率有所提升，但是我们希望能够更进一步缩短响应时间，完成预期目标。在采用方案二来调整数据模型后，SQL 执行时间从原来的 5 秒达到 63 毫秒响应时间，查询响应时间得到显著提升，满足我们对查询响应毫秒级的目标。
同时，我们借助 Grafana 查看 Apache Doris 查询性能，发现宽表构建的方案能够使查询时间从原来的十多秒缩短至百毫秒内，服务器也不再出现抖动的情况。
启用 SQL 缓存，节省服务器资源
采取宽表构建方案后，为了进一步提升查询性能，我们还启用了 SQL 缓存，帮助 T+1 报表场景实现高效查询性能：
在启用缓存之后，基本所有查询时长都在个位数，最终达到单用户访问页面在 4 秒内加载的成果；
在 30 个指标同时进行时（SQL 指令超 120 条），接口都可以满足 600ms 内返回；
在并发场景下，最优 TPS 达到 300， CPU、内存、磁盘和 IO 满足 80% 以下；
经评估，我们发现在官网推荐的测试集群规模下，Apache Doris 都可以缓存上万指标，极大节省了资源。
目前，金融壹账通基于 Apache Doris 实现了指标统一构建、查询、治理的一体化数据平台，为金融机构提供了全面的指标分析与展示，智能的指标生命周期管理等服务。在这样的平台建设下，集团内外多场景取得了非常显著的成果，截止目前，完成上万活跃指标、上千分析维度的积累，加工形成了上万个看板，减少了 30 % ETL 开发工作量。未来，公司将基于 Apache Doris 不断探索与优化，我们将重点推进以下几个方面的工作：
平台实时分析：基于 Apache Doris 构建湖仓一体，结合 Flink CDC、Apache Iceberg 共同构建统一实时分析。
平台物化视图：期待新版本亮点，探索多表关联下的查询优化，比如构建多表物化视图。
其他产品迁移：将中台的其他产品迁移至 Apache Doris。目前，标签平台基于 Elasticsearch 存在一定的使用问题，未来我们也准备将该平台迁入 Apache Doris。
# 相关链接：
SelectDB 官网：
Apache Doris 官网：
Apache Doris Github：
https://github.com/apache/doris
开源技术论坛：